1. Field of the Invention
The present invention relates to a method, system, and program for accessing device driver functions.
2. Description of the Related Art
A device driver is a program that includes device specific commands to communicate with and control attached devices. The device driver provides an interface between an operating system, such as Microsoft Windows®, Linux®, Unix®, etc., and a device, such as a network adaptor card, printer, video controller, etc., to enable the operating system and application programs executing therein to transmit commands to access information and control the device. In the Linux operating system, a user application program calls a device driver application program interface (API) via special IOCTL system calls to perform device related operations, such as getting network device statistics and setting device parameters such: as the Media Access Control (MAC) address for the device packet filtering, the maximum transmission unit (MTU)—which is the largest physical packet size transmitted on the network, etc.
The operating system runs a kernel, which is a central module of the operating system that is typically loaded first and remains in memory. The kernel is responsible for managing the execution of tasks and resource allocation, such as memory and processing resources. Tasks assigned by the kernel may execute in kernel mode or user mode. In kernel mode, tasks such as scheduling the running processes, interrupt handling, direct memory access, etc., are performed. In this mode, rescheduling (such as sleep operations) is not always allowed. User mode is for operations, such as running user applications and executing system service calls for applications. In this mode, rescheduling is allowed. Normally device driver APIs, such as the IOCTL commands, are initiated by system calls and therefore executed in user mode. Hence, device drivers are usually coded to process those APIs in a manner where processing may be rescheduled.
A kernel module, either statically linked or dynamically loaded, runs within the kernel and manages execution of code that must run at high priority and that needs privileged access to kernel resources. A device driver for example is a kernel module. An intermediate driver that is layered between the operating system and device drivers, and implements device teaming and other advanced features is also a kernel module.
A kernel module such as an intermediate driver usually operates in a high context (kernel mode), such as soft IRQ context (which includes timers, receive and transmit flows of an intermediate driver—formally known as bottom halves) or hard IRQ context. In certain situations, a kernel module may need to call the device driver's API directly. However, as discussed above, because the device driver's API is coded to run in user mode, this could cause a system crash.